home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CD ROM Paradise Collection 4
/
CD ROM Paradise Collection 4 1995 Nov.iso
/
hobby
/
gim_308.zip
/
GIM14.DOC
< prev
next >
Wrap
Text File
|
1994-12-25
|
36KB
|
686 lines
CHAPTER 14 Using GEDCOM to Share Genealogical Data
Like most major genealogical computer products, GIM supports the GEDCOM
standard. This standard allows different products -- even radically
dissimilar products -- to share genealogical data with one another.
In effect, this means that you can create a GIM folder from the
genealogical data of virtually any product which also supports the
GEDCOM standard -- even if that product runs on a non-DOS platform like
UNIX or the Macintosh. Similarly, you can share your GIM folder with
any of these other products.
This chapter will tell you everything you ever wanted to know about
GEDCOM, and GIM's implementation of GEDCOM. More or less in this order,
this chapter will answer the following questions:
AN INTRODUCTION TO GEDCOM
What is GEDCOM? Why is it important?
Where does it come from? Who uses it?
GIM FOLDERS AND GEDCOM (or "There and Back Again")
How does GIM use GEDCOM?
How do I produce a GIM folder from a GEDCOM data file?
How do I produce a GEDCOM data file from a GIM folder?
What do GIM's different GEDCOM destinations mean, and why do I
need them?
What about character sets?
ADVANCED GEDCOM TOPICS
Is GIM able to create folders from GEDCOM data that represents
unrelated lists of persons, such as from the Social Security
Death Index (SSDI) or the International Genealogical Index
(IGI)?
If I export my GIM folder to a GEDCOM file, and then read that
GEDCOM file back into a second GIM folder, will the second
folder be any different from the first? If so, in what ways,
and why?
GEDCOM MISCELLANY -- OPTIONAL READING FOR THE INTENSELY CURIOUS
Where can I go to read the documentation which defines the
GEDCOM standard?
How strictly does GIM adhere to the published documentation?
And now, after that introduction, and without further ado, let's dive
in with both feet:
AN INTRODUCTION TO GEDCOM
What is GEDCOM? Why is it important?
"GEDCOM" is an abbreviation for GEnealogical Data
COMmunication. As its name implies, it is a method for
communicating -- sharing -- data between different and
often radically dissimilar genealogical sources.
In essence, it's a common language that one computer must
speak if it intends to make sense to any other computer.
Every genealogical computer product speaks its own
language, so to speak; it runs on a particular operating
system (such as DOS, UNIX, or the Macintosh) which no
other operating system can understand; and even if it
runs on the same operating system as another product, it
typically reads and writes data on your hard disk in a
way that no other product can reliably interpret.
If this sounds chaotic, it's because it is chaotic. All
of these "languages", if you will, are something like the
Tower of Babel, and this situation is never going to get
any less chaotic than it is now.
Without something like the GEDCOM standard, none of these
products would be able to communicate with any other.
However, the GEDCOM standard serves as a sort of "common
second language", through which all genealogical computer
products can communicate.
Where does it come from? Who uses it?
GEDCOM is defined by the Family History Department of The
Church of Jesus Christ of Latter-day Saints, and it is
copyrighted by the Corporation of the President of the
Church of Jesus Christ of Latter-day Saints.
Documentation describing the GEDCOM standard is published
by the Family History Department, and is available from:
Family History Department, 3T
50 East North Temple Street
Salt Lake City, UT 84150
GEDCOM is implemented (to varying degrees) by all major
genealogical computer programs, and by many others.
GIM has been registered with and approved by the GEDCOM
Developers Group of the Family History Department, as
have many other computer software products.
GIM AND GEDCOM (or "There and Back Again")
How does GIM use GEDCOM?
All of the GIM's GEDCOM functions described below are
available from GIM's Folder Area by pressing the F5 key.
In the GEDCOM Area, there are two basic options:
F1, the GEDCOM Import function, will create a GIM folder
from an existing GEDCOM file.
F2, the GEDCOM Export function, will create a GEDCOM file
from an existing GIM folder.
How do I produce a GIM folder from a GEDCOM data file?
First of all, you must have a GEDCOM file to work with.
The LINCOLN sample GEDCOM files that were (or should have
been) included on your GIM software diskette are
examples.
GEDCOM files can be obtained from a number of places.
Most commonly, they are produced by another genealogical
computer program (e.g., FamilySearch), although GEDCOM
files for such things as European royalty, Mayflower
passengers, and United States Presidents are readily
available from various sources.
Take your GEDCOM file and place it somewhere -- on a
floppy disk, on your hard disk, or wherever.
Then enter the GEDCOM Area by pressing the F5 key from
the Folder Area. Press the F1 key to import the GEDCOM
file into your GIM folder.
A screen that looks like the Folder Area will appear; use
it to point to your GEDCOM file and press return.
Another screen that looks like the Folder Area will
appear; use it to point to the directory where your new
GIM folder should appear.
After that's done, the process is automatic, and will
require no interaction from you until it's all over.
When the GEDCOM Import process is all over, you will want
to use the GIM Utilities -- F5 from the Multi Area -- to
reset GIN numbers, to match PIN and GIN numbers, and
finally to check the folder for data integrity. See
chapter 15, entitled "Utilities for a Folder", for more
details. It is highly recommended that you DO NOT OMIT
THESE STEPS!!!
You may encounter any of the following items when
importing a GEDCOM file to a GIM folder. Some of them
are normal, and some are genuine problems. Here are
descriptions of the issues, and their remedies:
1. You may be warned that the GIM folder that you are
trying to create already exists. In this case you
will be prompted to verify that you want to overwrite
the existing folder. This is normal; however, be
very careful how you answer this, because if you
answer "yes", you may not be able to recover the
overwritten folder.
2. If you try to import or export when directory, file,
or folder names are empty, GIM will complain and ask
you to try again. This is normal.
3. If you try to import or export when directory names
are not blank, but do not exist on your system, you
will be asked whether you want GIM to create them.
This is normal. Be careful how you answer, because a
"yes" answer will cause the directory to be created,
and a "no" answer will cause GIM to use the current
directory; however, neither answer will abort the
import or export function.
4. When the import begins, GIM will display each of the
names of persons and families that it encounters in
the GEDCOM file. It will also display comments about
who created the GEDCOM file, when it was created, and
by what software product. GIM will also include
these notes in your GIM folder's Folder Notes; press
control-F5 from the Multi Area to view them.
5. This item is probably the most critical. While the
import function is underway, GIM may encounter a
GEDCOM line that it doesn't expect, or doesn't know
how to deal with.
This is not desired behavior. It could be caused by
all kinds of things, including a software error in
GIM, and including a software error in the program
that produced the GEDCOM file.
GIM will report all such things in the lower window
of the GEDCOM Import Area, and will also report them
in a log file that has the same name as your GEDCOM
file, but with the extension .LOG. You will be asked
to send your GEDCOM file and this LOG file to the GIM
Authors. Please do so; this will help us fix GIM to
make it more robust.
How do I produce a GEDCOM data file from a GIM folder?
Naturally, you must have an existing GIM folder before
you can use this function. The LINCOLN sample folders
that were (or should have been) included on your GIM
software diskette are examples, but we assume that you
have one or more of your own.
Enter the GEDCOM Area by pressing the F5 key from the
Folder Area. Then press F2 to export your GIM folder to
a GEDCOM file.
As you did with the GEDCOM Import, select your GIM folder
and your destination directory using the Folder-Area-like
screens that appear.
Next, it is necessary to select a destination. There are
several destinations available: PAF 2.2 (or later),
Ancestral File, TempleReady, Universal, and GIM. The
meanings for these will be explained in a moment; for
now, type U for Universal, which is the recommended
choice for most purposes.
Next, it is necessary to select a character set. The
choices are: No diacritics, IBM PC, and ANSEL. These
will also be explained in a moment. For now, pick IBM
PC, which is sufficient for the purposes of this example.
Once that's done, the export process is automatic, and
will require no interaction from you until it's all over.
You may encounter any of the following items when
exporting a GIM folder to a GEDCOM file. They are
normal:
1. You will be warned if the GEDCOM file that you are
trying to create already exists in the directory you
named. You will be asked if you want to overwrite
the old file with the new one.
2. If you try to import or export when directory, file,
or folder names are empty, GIM will complain and ask
you to try again.
When the export begins, GIM will display each of the
names of persons and families that it encounters in the
GIM folder as it writes them to the GEDCOM file. There
are no other problems that you are likely to encounter
when you are doing a GEDCOM export.
What do GIM's different GEDCOM destinations mean, and why do I
need them?
The different GEDCOM destinations are:
1. PAF 2.2 (or later)
Select this destination if your GEDCOM file is going
to be read into version 2.2 (or later) of Personal
Ancestral File.
Selecting this destination will cause GEDCOM to create
a GEDCOM file that, let us say, knows about PAF's
limitations. Among other things, PAF wantonly
ignores any GEDCOM notes other than those associated
with persons -- which means that all family notes and
all event notes must be bunched together in one pool,
or PAF will ignore them. Selecting a destination of
PAF 2.2 will accomplish this.
(Selecting a destination of PAF 2.2 will also
translate LDS temple names into their five-letter
abbreviations. The Ancestral File destination also
performs this translation.)
We recommend that you use it whenever you know that
you're sharing data with a PAF user.
There is no destination for PAF 2.1 or for earlier
versions, because those versions deal with GEDCOM in
a very weird way. Actually, it's not weird; it's
just old. The GEDCOM standard has changed with time,
and those old versions of PAF are incompatible with
the current standard. We have elected not to support
that older implementation, partly because it's so old
-- PAF 2.2 is based on the October 1987 version of
the GEDCOM standard! -- but mainly because we almost
never see it anymore.
2. Ancestral File
This should be used as a destination whenever you
plan to submit your genealogy to the LDS Church's
Ancestral File.
As stated earlier, GIM is registered and approved by
the GEDCOM Developers Group of the LDS Family History
Department for submitting GEDCOM format data to their
Ancestral File.
When you use GIM to submit data to Ancestral File,
use this destination to create your GEDCOM file.
This destination is essentially the same as the
Universal destination, with two exceptions: it uses
five-letter abbreviations for LDS temples; and it
explicitly lets the LDS Family History Department
know that you intend this GEDCOM file to be included
in its Ancestral File database. (For GEDCOM experts:
this means that it sets the DEST tag to ANSTFILE,
which is what the Ancestral File people expect.)
This destination formats notes in the same manner
that the Universal destination does; however, we have
recently been told authoritatively that the Ancestral
File ignores all notes sent to it, so the note format
is essentially irrelevant. We leave them in, knowing
that they won't be used, for the very sensible reason
that doing so puts the responsibility for omitting
them on the proper shoulders -- that is, not on ours.
For more information about contributing to Ancestral
File, see the FamilySearch publication entitled
"Contributing Information to Ancestral File", which
is available from most LDS Family History Centers,
and which may be ordered at no charge from the Salt
Lake Distribution Center (see Part C of Chapter 10 of
this GIM documentation for their address); give them
order number 34029. You might also want to get the
publication "Correcting Information in Ancestral
File". That order number is 34030.
3. TempleReady
A number of GIM users have asked for the ability to
create TempleReady diskettes using GIM. If you are
one of those, this is the destination to use.
When this documentation (and other literature) refers
to a "TempleReady diskette", what is actually meant
is simply a diskette which contains a GEDCOM file
which has "TempleReady" as its destination (that is
to say, for GEDCOM experts, the GEDCOM file must have
the line "1 DEST TempleReady" in its HEADer record).
(This means that you shouldn't try to use any other
GIM GEDCOM Export destination if you intend to use
TempleReady; TempleReady won't recognize that GEDCOM
file, even if it is perfectly valid in every other
way.)
So to create a TempleReady diskette using GIM, select
the TempleReady destination from a GIM GEDCOM Export.
The resulting GEDCOM file can then be placed on a
diskette and taken to your local LDS Family History
Center for use with FamilySearch.
Please note, when doing so, that ALL of the families
and individuals in your folder will be included in
the resulting GEDCOM file. This is in contrast to
PAF, for example, which prompts you to identify
families and individuals one by one for inclusion on
the TempleReady diskette. Because of this, if you
only want to include a single family or a single
branch on your GIM TempleReady diskette, it is
important that you prune off that family or branch
into its own folder before selecting this option.
(See chapter 12, "Pruning Folders", for details.)
It is strongly recommended that you double check your
submission info and make sure that it has been
entered, and that it is correct. (See chapter 10,
"Generating Printed Forms", for details about the
submission info.) (Note that if you prune a folder
from a parent folder, the parent's submission info
will carry over into the pruned folder.) TempleReady
will prompt you for this information, which will be
included automatically from your submission info, so
you can save yourself a step if your submission info
is accurate to begin with.
After you select TempleReady as your destination (and
after you select a character set), GIM will prompt
you for a temple name. This assumes that your names
will go into a Family File in your name at the temple
nearest you. GIM requires that you enter the name
(or abbreviation) of one of the LDS temples at this
point, just like you would if you were entering a
place name for a person's endowment or sealing.
If you intend to submit your names to a Temple File
rather than a Family File, and if you don't care what
temple the names are submitted to, then enter the
name of any temple in response to this query. It
won't matter what name you pick in that case.
Let the GEDCOM export run to completion, then (like
we said earlier) the resulting GEDCOM file can be
taken to your nearest LDS Family History Center for
use with FamilySearch. Your Family History Center
should have written instructions describing how to
use FamilySearch, so we will refrain from describing
its use in detail here.
Specifically, your local LDS Family History Center
should be able to provide you with a FamilySearch
user's guide, which is several dozen pages long, and
which contains detailed instructions on the use of
TempleReady, as well as the other components of
FamilySearch.
They should also be able to provide you with a four-
page guide entitled "Introduction to TempleReady".
This may be obtained at no charge from the Salt Lake
Distribution Center. See Part C of Chapter 10 of
this documentation, entitled "Generating Printed
Forms", and subtitled "The Preprinted Family Group
Record", for their address. When you contact them,
ask for item number 34596.
4. Universal
You will notice that there is no destination
specified for any of the other myriad of genealogy
programs that are available, such as Brother's Keeper
and others. This is partly because we aren't as
familiar with them as we are with PAF and with
Ancestral File.
But mainly, it is also because we expect most of
them to be more fully GEDCOM compliant than PAF is,
(strange as that may sound). In other words, we
expect the Universal destination to work for most
GEDCOM-compatible programs in most cases.
The Universal destination adheres in all ways to the
GEDCOM standard, and as such it should theoretically
be accepted by any program that speaks GEDCOM.
It differs from the PAF destination chiefly in its
use of notes, which are attached to families and
events, instead of lumped together in one pool for
each individual. It differs from the Ancestral File
and PAF destinations in its use of long names for LDS
temples, instead of the standard five-letter
abbreviations that these LDS-oriented software
products expect.
Naturally, if you encounter a program that can't or
won't read a GEDCOM file that is generated with a
destination of Universal, we would like to know about
it. When that situation is brought to our attention,
we will create a new destination category for that
software product, and use it to accommodate that
product's needs.
5. GIM
This destination creates a GEDCOM file which can be
re-imported into GIM in such a way as to create a
resulting GIM folder which was as much like the
original folder as possible, while still adhering to
the GEDCOM standard.
To some degree, the resulting GIM folder will not be
exactly the same as the original; it cannot be, and
still be transmitted through a GEDCOM file which
adheres to the standard. For details, see the
discussion of this question below, under the section
heading "Advanced Genealogical Folder Exchange".
At the present time, this destination differs from
the Universal destination only in the fact that
source notes and research notes are denoted by the
identifier "GIM SOURCE NOTES" and "GIM RESEARCH
NOTES", whereas with the Universal destination, they
are only identified as "SOURCE NOTES" and "RESEARCH
NOTES".
What about character sets?
There is a certain amount of confusion in the computer
industry regarding the use of diacritical marks such as
umlauts, accents, and so forth. While the industry is
pretty well settled on the way to represent the basic
Latin alphabet used by the English language, this is not
at all true of the marks use by foreign languages.
Without wanting to get too technically involved, let's
just say that there are a number of different ways of
representing these marks, and every computer system uses
its own way of doing so. As a result, there is one
character set for the Macintosh, another for MS-Windows,
half a dozen or more code pages for MS-DOS, no one of
which is compatible with any other. Further adding to
this alphabet soup of character sets are a long list of
sets defined by international organizations.
In an effort to address this problem, the GEDCOM standard
settled on one of the international standards, called
ANSEL (which stands for "American National Standard for
Extended Latin Alphabet Coded Character Set for
Bibliographic Use"). The fact that GEDCOM defines a
standard is the good news. The bad news is that not
everybody accepts or implements it. As a result, there
are still many genealogical software products which read
and write diacritical marks in their own native character
set, which naturally makes life miserable for (let's say)
a user of DOS software who is trying to share data with a
user of Macintosh or MS-Windows software.
Now, with that much background, let's get back to the
question, "What about character sets?"
GIM currently provides support for three: No diacritics,
IBM PC, and ANSEL. A fourth one -- MS-Windows -- will be
available in a near-future release. These three are
discussed below in turn.
NO DIACRITICS:
When you select any of the other destinations,
GEDCOM translates any diacritics it encounters into
the standard alphabet, according to standard rules.
For example, it translates "ü" as "ue", and trans-
lates "å" as "aa". (The rules that are used are
described in detail in Appendix E.)
This is principally of use (or interest) only when
sharing GEDCOM data with PAF, because PAF simply
doesn't handle diacritics very well at all. No
matter whether the native (IBM PC) or the ANSEL set
is used, PAF simply ignores the diacritic; the
result is that the name "Müller" becomes simply
"Muller".
Selecting the "no diacritics" character set at this
point is at least a simple-minded step ahead of PAF.
This choice replaces "ü" wherever it is found with
the standard "ue", meaning that "Müller" becomes
"Mueller", which is a slightly more acceptable
transliteration of the name.
As a result of all this, the "no diacritics"
selection is recommended for use with PAF, and is
not recommended for any other use.
IBM PC:
This is the native character set used with MS-DOS,
assuming that you are using the United States code
page (437). GEDCOM transfers using this character
set are quite a bit faster than using any other
character set, because there is no translation
involved. On the other hand, this character set is
not at all portable, and its use is technically in
violation of the GEDCOM standard.
However, its use is supported by GIM because so many
other genealogical software products provide it, and
in fact some of them don't provide anything else.
This character set is recommended if, and ONLY if,
you know that you are communicating with another
MS-DOS machine which is using the United States code
page (437).
ANSEL:
This is the GEDCOM standard character set. As
discussed above, this character set preserves
diacritical marks across all computer systems, as
long as they are all implementing the ANSEL
character set correctly.
This character set is recommended for all destina-
tions, except for use with PAF, and except in cases
where you know that the receiving software doesn't
speak ANSEL. In particular, it is especially
recommended for use with the Ancestral File and
TempleReady destinations.
ADVANCED GENEALOGICAL FOLDER EXCHANGE
Is GIM able to create folders from GEDCOM data that represents
unrelated lists of persons, such as from the Social Security
Death Index (SSDI) or the International Genealogical Index
(IGI)?
Absolutely! Naturally, in that case, the GIM folder
will consist of unrelated individuals -- in other words,
there will be lots of persons and notes in your folder,
but no families.
GIM has no problem dealing with this kind of folder, but
you may think that such a folder may not feel natural.
That's because GIM is designed with family relationships
in mind, and when they are absent, it's not possible to
use arrow keys to navigate around the folder.
However, all of GIM's other functions are available, and
they are often valuable tools in such cases. GIM LISTS,
for example, can be used to search each of these persons
for items of interest; but just be aware that you can't
search for families, because there aren't any.
In other words, yes it can, but don't let the result
bother you too much.
If I export my GIM folder to a GEDCOM file, and then read
that GEDCOM file back into a second GIM folder, will the
second folder be any different from the first? If so, in
what ways, and why?
There are a couple of items which will not translate
correctly in such a scenario. These are as follows:
GIM's "code" value -- which is available from the Person
Edit screen -- is not included in a GEDCOM export.
Naturally, therefore, it won't be restored when the
GEDCOM file is re-imported.
GEDCOM does not allow forward slashes in person names,
but GIM does. If forward slashes are used in person
names, they will be translated into backslashes when the
GEDCOM file is created. Naturally, when this GEDCOM file
is re-imported, the backslashes will not be restored.
(How can the GEDCOM importer know whether a backslash was
originally a backslash or a forward slash?)
The folder notes will be quite different in the two
folders. This is because a GIM folder's folder notes are
not included in a GEDCOM export, and the GEDCOM import
creates brand new folder notes from scratch during the
import process.
GEDCOM MISCELLANY -- OPTIONAL READING FOR THE INTENSELY CURIOUS
Where can I go to read the documentation which defines the
GEDCOM standard?
As we stated earlier, the documentation can be obtained
from the Family History Department of the LDS Church.
This documentation is intended for programmers only, and
is not necessary for non-programming purposes.
How strictly does GIM adhere to the published documentation?
To the best of our knowledge and belief, GIM's GEDCOM
Export functions produce GEDCOM files that are fully
compliant with the most recent publication of the GEDCOM
standard. GIM produces GEDCOM files that can be read
without difficulty by PAF and Brother's Keeper, and GIM
produces GEDCOM files that are approved for Ancestral
File submissions by the Family History Department of the
LDS Church.
The GEDCOM standard is, however, very rich and powerful,
and it is not unlikely that other software products may
produce GEDCOM compliant files that GIM can't understand.
GIM has made every attempt to understand and comply with
the GEDCOM files produced by most major software
products, but we can't guarantee that we can understand
them all.
As stated earlier, if you should encounter instances
where GEDCOM files are incompatible with other software,
the problem could be either with GIM or with the other
software; in either case, we encourage you to bring them
to our attention.
